Table of Contents for

Communicating Design: Developing Web Site Documentation for Design and Planning, Second Edition

Chapter 4. Concept Models

A concept model is a diagram that shows the relationships between different abstract ideas. You can apply the concept modeling technique in a variety of circumstances to explain different aspects of a web site. Also known as concept maps or affinity diagrams.

In addition to communicating ideas, design artifacts help you, the designer, work through difficult problems. Putting a structure on paper, sketching a screen layout, or summarizing user needs can all help you find new insights and new inspiration. I won’t pretend to understand the neuroscience behind this. All I can tell you is, from experience, whenever I think I can neglect this part of the process I’m proven dead wrong.

Concept models swing more toward the personal side of the spectrum than perhaps any other diagram in this book. It is the diagram I most often keep to myself, rarely sharing it with clients and occasionally not even other team members. It is one of the first diagrams I build, almost immediately as I start familiarizing myself with a project’s requirements. It helps build my comfort level with a project’s scope and the related domain of information.

I transition concept models from hand-drawn sketches to vector art faster than any other diagram. Putting them into a diagramming application lets me manipulate their structure and content quickly, allowing me to see the ideas in new ways.

What ideas? What is it that a concept model helps to envision? Web sites have underlying structures: More than just navigation menus, a site’s skeleton is the collection of stuff that makes it what it is. Imagine taking the concept of “article” or “story” away from CNN.com. The site would be fundamentally different.

Table 4.1. Different kinds of content that typically appears on sites.

The complexity of web sites is not just in the level of interaction they permit, but also in their sophistication in dealing with the underlying information. The role of the concept model is to help designers iron out the structure for that information. Through modeling the concepts, designers learn:

• How to link content together

• How to expose content at different areas of the site

• What kinds of information should be associated with each concept

• The kinds of interactions users might expect with different kinds of information

• The relative priorities of different kinds of content or features

• The concepts that will serve as central “home” areas of the web site

• Which concepts will provide a context to view other kinds of information

Introducing Concept Models

A concept model follows the format of a few other diagrams in this book—shapes connected by lines. In this case, the shapes (sometimes called nodes) represent concepts. The lines represent the relationships between the concepts. Both site maps and flowcharts belong to the same family, but concept models are, in a sense, a superset. They don’t prescribe a particular type of relationship or presume a particular type of node. Table 4.2 differentiates between concept models and site maps around some fundamental characteristics.

The one constraint on concept models is that the nodes are nouns and the connections are verbs. Each node-link-node combination can read as a sentence, as in:

Concept Models Are Diagrams.

Table 4.2. Contrasting concept models and site maps. How do concept models differ from site maps? Let me count the ways...four. There are four ways.

It’s not much of a constraint; the format offers much flexibility, which cuts both ways. Sometimes it can be hard to determine what to include in the model and what to leave out.

How Concept Models Help: A Short Preview

Concept models fill a void between requirements and design, between stating the problem and solving the problem. Designers must internalize the design problem. Somewhere between “getting into the user’s shoes,” recognizing technical constraints. and understanding the business context there is a need for a unified vision of the product. A concept model establishes a consolidated, holistic view of what the thing is, what it does, and who it helps.

Concepts in the model translate to different parts of the site. A concept model can help determine your strategy for establishing templates, components, modules, navigation, metadata, and the underlying structure of a content management system. It can provide insight into the range of interactions users will need to perform. Short, right?

Figure 4.1. A concept model to explain concept models. I thought you might like the recursion.

A rose by any other name

Someone once asked me how concept models are different from affinity diagrams. Affinity diagramming is an exercise to help a group of people identify similarities across a broad set of qualitative information, like observations during user research. Affinity diagramming is like any other grouping and prioritization activity—meant to consolidate a range of information and identify patterns. Beyer and Holtzblatt use affinity diagramming to consolidate observations from their user research technique, contextual inquiry, and identify new insights about the target audience.

Which sounds a lot like concept modeling.

Affinity diagrams don’t follow the exact format I describe here, which is based more on Novak’s concept mapping work (see sidebar on History of Concept Models). Beyer and Holtzblatt put a strong emphasis on consolidation through categorization and grouping, whereas my concept models don’t necessarily revolve around a hierarchy.

Concept modeling is not unique to web design, nor is that the only name for this activity. Explicitly connecting ideas through visualization is a technique that comes in many flavors. I can only urge you to find the flavor you like best, or, like Ben and Jerry, invent one that suits your taste... er... style and approach.

Figure 4.2. Concept models establish frameworks that give the design team a vocabulary for talking about a domain. This model about comics clarifies some of the more obscure concepts and describes the key relationships.

Challenges

Because it’s an artifact to facilitate your thought process, the challenges with concept models—more than any other artifact—have to do with getting out of your own head:

• Analysis paralysis: There’s nothing more absorbing than fiddling with a model. Whether you go back and forth on the diagram’s layout or engage in an endless internal debate on the right structure, you can lose sight of its purpose. Ultimately, you don’t need to get everything “right,” you need to get it “right enough.” Take your deliberations far enough to help you move to the next step. Have a good sense of the range of templates you’ll need? Then stop messing with the line weight on your connections and move on!

• Practicality: Even if you bookend your thought process effectively, you might create a document that doesn’t effortlessly take you into the next stage of the design process. Any good artifact must further your thinking, whether in understanding the problem better or creating a meaningful design to address the problem. Concept models are inherently fussy and force you to dwell in abstract concepts. The result can easily be an output with no obvious next step. Knowing when to stop (see “analysis paralysis”) is key, but knowing what’s going to offer the most utility is also important.

• Perspective: Like other artifacts, concept models depict a slice of reality, telling a story about how things are or ought to be. Unlike a flowchart, for example, a concept model has no clear protagonist, no obvious perspective. Put another way, two people creating a flowchart of the same process will come closer to each other than two people creating a concept model of a set of ideas. As self-indulgent as concept models can be, your models can be more successful if you incorporate multiple perspectives—or at least acknowledge that there may be several different ways of looking at the world. Perspectives can influence which concepts you incorporate and how you describe the relationships between them.

The previous challenges may rest on one central challenge: Concept models are, out of necessity, an abstraction. They don’t talk about things, they talk about kinds of things. They don’t represent the physical manifestation of any content or interface element. Their elements don’t necessarily directly translate to parts of the interface. They remain at the highest possible levels of content, not digging into the dirty details of what goes where.

I’ve almost convinced myself to stop doing these things. Potential lack of practicality? Risks to the project plan? Abstract thinking? That can’t be fun for anyone. And yet, I find myself turning to modeling project after project. As a tool for design, they help me start to shape structures, if only in the most basic way. As a tool for understanding, they help me gain insights into a particular domain to get the lay of the land and to give myself a starting point for design. Drawing pictures, even quick ones to lay some groundwork, yields more fruitful design work than simply starting with screens.

Anatomy of a Concept Model

Concept models illuminate domains of information, subjecting them to structured classification and relationships. The advantage of a concept model is that it doesn’t force a hierarchical relationship among the domain’s concepts. To be effective, the concept model must be clear about what’s included and how the concepts and domains all relate to each other.

This section discusses the layout and style of concept models. Subsequent sections discuss choosing appropriate concepts and some of the weird things that happen when we try to boil the world down into circles connected by lines.

Table 4.3. Three layers of concept models and the components of each.

Layer 1: The Basics

With concept models, we have two basic building blocks to work with: nodes and links. The format for a concept model suggests only that the nodes represent nouns and the links represent verbs describing the relationships between them.

Nodes

Use circles to represent nodes. The advantages of circles:

• They’re easy to connect with each other. Without sides (or with infinite sides, depending on your relationship with Euclid), it’s easy to attach links to a circle. A line that connects to a circle’s center is clean and easy to understand. The same thing with a square or other shape can be inelegant and yield “visual noise” that could confuse the diagram.

• They don’t crave a grid. Four-sided shapes want to live on a grid. Circles don’t need a grid to ensure legibility and visual appeal, which means they can get close to each other pretty easily, and you’re not dependent on layout to convey a sense of hierarchy. A nice corollary to this is that aligning circles to a grid is a powerful communication device. Without doing anything besides lining them up, you can imply a particularly strong or central relationship.

• Squares and rectangles imply screens or pages. This may be appropriate in some instances—when your concept model actually represents a network of templates—but if you’re laying conceptual groundwork, circles are good for concepts.

Figure 4.3. Nodes should be circles. Squares just don’t connect well.

Label your circles. A couple of tips:

• Remember, these are the nouns. The next section covers how to choose appropriate concepts.

• Use the plural. It’s easier to craft appropriate verbs in the links, and the purpose of these concepts is to generalize about the domain of information. Plurals don’t require an article (“a”, “an” or “the”), making it easy to construct sentences.

• Specificity is good, but use examples in a subtitle. Note that the sample concept model uses “Genres” as the main concept and “Fantasy” as the example.

Figure 4.4. Give your concepts specificity, under the main concept of “Genres” a specific example is given—“Fantasy.”

Links

Use lines to represent the connections between nodes. In concept models, the links always have directionality. That is, they’re always read as one-way from one node to another. Always label your links; I always regret it when I leave them off. Some ideas for good labels:

• Remember, these are the verbs. They should describe the relationship between one concept and the other by describing how the one acts on the other.

• Avoid “to be.” This isn’t a Strunk and White–like grudge against the passive voice. “To be” implies belonging, a hierarchical relationship. It doesn’t illuminate the relationship. You’re using a concept model because the relationships between the concepts are more interesting than a series of nested categories.

• Avoid wishy-washy modifiers. If you try to hedge your relationships by using “may” and “might”, your whole model will be one giant apology. A good concept model is like good writing—authoritative and confident. Readers understand implicitly that not every relationship will hold true in every instance.

• Avoid constructing multinode sentences. You might be tempted to concoct a chain of relationships to create a more complete picture. (The next layer talks about how to deal with more complex relationships.) Generally speaking, I try to keep my node-link-node relationships self-contained. Although it’s important to capture the complexity of reality, it’s more important to create an artifact that serves the design process. Standing at any node, you should understand how it relates to the concepts around it, outside the context of concepts two or more degrees away.

A set of nodes and their relationships may break this last rule, but only when they represent the “backbone” of the domain—the essential theme that ties everything together. The section Creating Concept Models describes different starting points and basic structures for concept models.

Figure 4.5. The challenges of multinode sentences: They lack of immediate context. Though the bottom version feels a little disjointed, the reader can start at any node and apprehend a complete thought. Using prepositions alone, in the top example, doesn’t illuminate the concepts.

Layer 2: More Detail

It won’t take long for you to run into severe constraints with the simple concept models described with layer 1 elements. Indeed, reality frequently demands richer visualizations. The devices in the second layer extend basic node-link-node relationships to afford us more power in describing these complexities.

Table 4.4. Techniques for showing nodes, how they are similar or different in a concept model.

Distinguishing nodes with styles and backgrounds

Not every concept in your model is necessarily weighted the same. Some concepts are more central to the story. Others are more important to emphasize. Further, you might identify patterns in the nodes that are not immediately apparent from the relationships between them. You might want to highlight that some nodes represent people while others represent physical objects. In the case of the comic book model, for example, I could distinguish between concepts that allow me to classify and identify comics and those that have to do with the business of comics.

Determining appropriate distinctions and groupings will be discussed in Creating Concept Models, a few pages ahead. There are a few techniques for styling nodes to highlight the differences between them.

Similarly, you can use the same techniques to style the links between nodes. Of course, styling links has different implications. (See Table 4.5.)

Table 4.5. Techniques for distinguishing types of links between nodes in a concept model.

Figure 4.6. Differently styled nodes and links, even just using circles, fills, and lines, offer a lot of flexibility to communicating differences.

How much is too much? Readers need to know where to start and what to focus on. They need to come to a particular conclusion. Judiciously applied, styles can enhance the model’s ability to tell the story. But too many can further confuse the issue.

In the comics model, I used the heavy arrows around the perimeter to establish a framework for the whole diagram with the main relationships connecting the primary concepts.

The branched relationship

Sometimes, when I get down to the leaves of the tree, so to speak, describing the smaller details of a model, I’m capturing various facets of those small concepts. A single concept is linked to several smaller ones that, in and of themselves, serve only to describe the larger concept. Identifying unique relationships to each of these smaller concepts may be more trouble than it’s worth.

Enter, the branched relationship. A single label identifies all the links between the larger concept and the smaller ones. It looks somewhat different: instead of a single line between the concepts, the larger concept has a line that branches and the label sits on that single “trunk” or at the intersection of all the branched lines.

Figure 4.7. A branched relationship connects one concept to two others with the same verb. In this case, the value of a comic depends on two things—its condition and important milestones in the story.

There are any number of reasons why you might use this approach, but two specifically come to mind:

• The smaller concepts are descriptive of the larger concept. In this case, it’s useful to identify specific aspects, perhaps because you want to highlight particular properties of the larger concept.

• The smaller concepts represent various possible states or conditions for the larger concept.

Direct and indirect objects

The grammarians among you might start to wonder about the simplicity of sentences based on noun-verb-noun. The domains you’ll be modeling will likely demand more complex relationships. Breaking down the language of a concept model, the two nodes act as a subject and object: Subject acts on object.

This may be appropriate for most relationships you need to describe. In some instances, however, the relationship makes sense only with the addition of an indirect object.

In my own models, I’ve found that central ideas need to appear throughout the model. They, in a sense, mediate relationships between other nodes. In our running example, concepts like “Comic Books” and “Stories” are central concepts that may be indirect objects in many of the other relationships.

In some cases, you can change the perspective to frame the same relationship in a different way:

Sellers sell comic books in Stores ->

Stores [are] owned by Owners

In other cases, you can phrase the verb to swap the object and indirect object:

Distributors distribute comic books to Stores ->

Distributors supply Stores (with comic books)

Such an approach is grammatically and stylistically questionable, but appropriate for the purposes of the model.

If you find you can’t effectively describe a relationship without mentioning another noun, consider embedding it in the link’s label. You can give it a distinct color, matching the color of the original concept.

Layer 3: From Model to Illustration

You can stop at layer 2. Seriously, if you don’t take your model beyond circles and lines, that’s OK, especially if you’re not likely to show it to anyone else.

But if you’re anything like me, you sometimes want a little more. You want a meaningful picture that’s fun to look at. If your project allows (or you have nothing better to do on the weekends) you might take some time to refine your model.

There’s no easy way to teach this in the space of a few pages, but here are some techniques that I use to refine my models.

Amplify a particular comparison

Successful diagrams let readers compare ideas. You might pick two concepts, or two groups of concepts, and massage the visualization to show the similarities and differences between them.

Figure 4.8. Comparing the business and the consumption of comics. This comparison emerged as I was evolving the model, distinguishing the experience of comics (bottom arc) from the business of making them (top arc).

Find a metaphor

Like a concept model, a metaphor is a way of organizing relationships between ideas. By using a metaphor, we’re mapping one domain to another and making inferences about the target domain based on knowledge we have about the mapped domain. In a less abstract way: When comparing arguments to battle, I’m mapping the elements of an argument (participants, discussion) to elements of battles (opponents, fighting, winners and losers). This comparison frames the concept of an argument in a particular way, and implies certain conclusions.

Look through the key relationships in your concept model. Is there one set that lends itself to a visual metaphor? Starting with that foundation, extend the metaphor to encompass other concepts in your original model. How does the metaphor explain relationships to other concepts?

Figure 4.9. Transforming simple models into beautiful illustrations is a hallmark of Stephen Anderson’s work. Driven by a small handful of concepts, Stephen elaborated the basic idea—a definition of user experience—into a visual metaphor that drives the point home. You can learn more about Stephen’s work at poetpainter.com.

Concepts as backdrops

A mature model will have a number of midsized concepts. Ideas that are crucial to the story, but serve as a bridge between the central ideas and the meaty details. Instead of using these concepts as a bridge, have them recede, using them as a backdrop for the more detailed concepts.

Figure 4.10. Receding concepts into backdrops can add depth to the model as well as communicate simple relationships with less visual noise.

Simplified story

Another technique to facilitate the transition from circles and lines to something more sophisticated is to strip out some concepts. With a smaller number of concepts, you can focus on showing the relationships between them instead of describing them through labels.

There are two ways to get to a simpler story:

• Focus on one part: A good model can show how seemingly unrelated things have important connections. That said, the conceptual leap from one end of your diagram to the other may not be the central part of the story. To generate a more visually appealing illustration, you can zoom in on one part of your model. This may yield one or two concepts serving as the central focus, and you can show how the more detailed and specific concepts relate to them.

• Focus on higher levels: Starting with the model’s primary concepts, keep only those nodes that are one or two degrees away, shaving off everything “lower” in the model. With trimmed details, the model becomes easier to shape into a picture. You can play up certain relationships and identify other visual devices for describing the major concepts. As you zero-in on how to tell the high-level story, you can decide whether it’s appropriate and feasible to incorporate the stripped-out details.

Creating Concept Models

Diagramming concepts can lead you down pretty abstract, esoteric, and sometimes unproductive lines of thought. A little planning goes a long way, at least by making some basic decisions about purpose, audience, and content. These will give the model focus and ensure you’re not spinning.

Basic Decisions for Concept Models

Sometimes I don’t know the answers to the following questions when I start modeling the concepts behind a new project. It’s a useful exercise for me, and I’ve become reasonably responsible about not getting pulled too far down the rabbit hole. That said, once the model is underway and I’ve got a better sense of range and scope, I also start to frame up what role the model will play on the project. Either way, as the model starts to form up, answering these questions can help give you a sense of focus.

What is the purpose?

In design, the purpose of high level conceptual thinking is to inform the entire process. At different stages of the design process, the conceptual model will serve different purposes. The chief purpose of a model is, in my mind, to answer the question, “What are we dealing with here?” It seeks to illustrate and frame the range, scope, and depth of the things we’re interested in.

While the answer to that question may shift and settle over the course of the project, its boundaries generally remain intact. The answer to that question, however, contributes to all the other decisions you and your team will have to make throughout the process. At the beginning, you might use a model to comprehend a new domain. As you get underway, the decisions might be about what’s in scope and what’s out of scope for the project.

Even the simplest concept models can help. I created a very simple model at the start of a project to help clarify some overlapping concepts (Figure 4.11).

Figure 4.11. To help inspire new ways of thinking about the product, I created this concept model to better understand all the different moving parts. It’s a pretty simple model, but it was enormously useful in clarifying the relationships. Note how this model completely evolved from circles-and-lines to more of an illustration.

Who is the audience?

“Well, that didn’t go so well.” So said my colleague Chris as we came out of a meeting where I presented a concept model to a group of business stakeholders. Boy, was he right. They just didn’t get it. Unless a model is fleshed out and highly illustrated (and perhaps even if it is), you’ll struggle to get any meaningful response. Table 4.6 explains why.

Table 4.6. Concept models can be difficult for people to understand.

The section up ahead that deals with presenting concept models can give you some ideas on how to fine-tune the model depending on whether you need to show it to a client or not.

Generally speaking, I create concept models for myself. If I need to solicit input from someone else, I’ll package the diagram to tell a specific story. Here are some things you can do to facilitate such a presentation:

Table 4.7. To make concept models more accessible, consider tapping into people’s strengths.

It’s a big investment, so I always double-check that I have the time and budget and ask myself, “What feedback do I want from this person? Is this the best way to get that information out of them?”

What should you include in the model?

What makes a good node? Four things should drive whether you end up including a concept in the model:

• Important to users: Through primary or secondary research, you will learn what ideas are central to the users’ experience of the site.

• Important to stakeholders: Interviews and requirements-gathering with stakeholders will reveal which ideas are important to them. These ideas are central to an organization’s conception of success.

• Meaningful landmark: Some concepts provide a useful way to link other ideas together. They serve as a central point or bridge two concepts.

• Offers insight: As you elaborate on your model, you may identify additional concepts that can help illuminate the underlying domain.

Figure 4.12. Good nodes are important to users, important to the business, provide a contextual landmark, or offer an insight.

After you have a first draft of your model, you can also try to bring “bad” nodes to the surface—concepts that don’t substantially contribute to explaining the domain. One way to do this is to pull out common words, concepts that are so broad that outside the context of the model it’s hard to determine what they might be talking about.

Figure 4.13. Common words are good opportunities to prune the model. One early version of the comics model included the concept “People,” which was easy to eliminate.

The links between nodes should all strive for greatest interest and appeal. You should seek out relationships that:

• Highlight the active: Use active verbs that describe how one concept affects, influences, or otherwise changes another.

• Evoke interface actions: Assuming all the concepts will translate eventually into information on the web site, all the links could reflect the various actions users might perform. While not a necessity, the exercise lays groundwork for doing subsequent design work. If you subscribe to the idea that all interactions with data can be reduced to CRUD (create, retrieve, update, and delete), here are some verbs that relate to each of those actions:

Table 4.8. Relationships in concept models may try to highlight the same sort of connection over and over again. These nuances, however, can have a major impact on the design process. “Create” could refer to something generated or yielded passively, as a by-product, or something with much more intent, like “composes”.

Table 4.9. Three basic structures for concept models. Each has its own place, and may be a useful starting point if you have no specific ideas on how to initiate the model.

How you should lay out the model?

Concept models start out messy. As you clarify the story and insights start to emerge, you may want to clean it up. The insights you learn should drive how you structure the model: They should tell you what concepts and relationships to prioritize.

My models tend to fall under one of three typical structures. These structures may be useful starting points once you’ve had a chance to move the concepts around the page a bit.

Note that it’s rare for me to start with one of these structures right off the bat. In my initial models I do not prioritize any concepts. Only after I see how the story emerges do I zero-in on one of these approaches as appropriate for providing a framework for the model.

Tips for Crystal Clear Concept Models

It’s not too hard to get some initial ideas down on paper, especially if you’re familiar with the domain. But if you don’t know much about it, you might get only a few nodes on paper before you get stuck. Here are some ideas for getting, you know, unstuck.

Do your research

Flesh out your understanding of the domain by reading up on it. Nothing gives you more nouns and verbs to draw upon than a few comprehensive, detailed descriptions of the business.

When I started an 18-month contract at the wireless division of the Federal Communications Commission (FCC), it was clear I knew nothing about the business. While the FCC’s web site was a good starting point, I also sought out other web sites that cater to the same target audiences. This afternoon of surfing gave me enough fodder to build up a model. Ultimately, the model was never shared with others, but was a good tool for me to become comfortable with the various players and underlying business model.

User research is even better. Transcripts of interviews are rife with concepts that are important and meaningful to users.

Look under the hood

If you’re stuck, pick a node and ask yourself, “What else can I say about this concept?” Unpack the concept, forcing yourself to be as specific as possible. If you need more specific questions, pretend you’re interviewing a person (not a circle) who knows about the concept or the domain.

One of the jargon words used in talking about comics is “mythology,” which informally refers to a character’s backstory. Because many popular characters have been around for decades, and have been subject to so many interpretations, there are multiple mythologies for some characters. This idea is difficult to model.

Some questions I asked myself about the “mythologies” concept in order to arrive at a more detailed model:

• What makes one mythology different from another?

• How do storytellers deal with multiple mythologies?

• What other concepts are affected by a character’s mythology?

Figure 4.14. Some details emerge only after forcing yourself to unpack a concept. In this early version of the comics concept model, I elaborated on the concept of a “mythology”. While it didn’t make it into the final model, I did keep “relevant milestones”.

In elaborating on this concept, I knew there was a relationship to another key idea—a universe. In short, one way to resolve competing or conflicting backstories is to place different versions of the same character in parallel universes. (And people wonder why comics aren’t more mainstream.)

It was difficult for me to think of a specific verb that created a relationship between Mythology and Universe, so instead I tried to think of concepts that “mediated” between them. This helped me flesh out this part of the diagram.

If you can’t generate answers or find them through research, capture the questions in the model itself. When you get to interview an expert, these questions can guide your agenda.

Move stuff around

If you have dozens of concepts, it may be challenging to find a central focus for the diagram. The best way to elaborate on the model, focus it, and find insights in the relationships is to move the nodes around. This might seem like an oversimplification, and a very mechanical way of iterating on the model. By moving concepts around, however, you can test out new kinds of relationships, explore positioning relationships in a new way, and zero-in on gaps in the model.

Build up then tear down

Since it’s difficult to picture the end state before you start a model, err on the side of too much information. Include concepts that may not be entirely relevant. Link a concept to as many others as you can. Your page will be covered with circles and lines, but starting with too much is part of the creative process, giving you more opportunities for insight. You’ll have to cut things out ruthlessly when it comes time to clean up the model, but the pruning process can also lead to insights.

To reduce links, look for triangles (Figure 4.15). Three interconnected nodes can indicate that one of the relationships is redundant. Eliminate the relationship between the two less important nodes, focusing on the relationship between the important node and the ideas that support it. Alternatively, identify a chain of nodes that tells the simplest story.

Figure 4.15. Reducing triangles from three connections to two can help clean up the model. Looking for triangles (like these from an early version of the comics concept model) can reveal opportunities to consolidate and focus the model.

To reduce nodes, eliminate words that are so common they are merely a convenient mechanism for bridging to other concepts. In an early version of the comics concept model, I used the concept “words” to encompass the different kinds of verbiage in a comic book–dialog, narrative, thoughts, and so on. Since I was already using the concepts “scripts” and “writers,” “words” felt unnecessary.

Figure 4.16. Redundant words make for good opportunities to simplify the model. Though writing a script is an accurate depiction of the comic authoring process, it may not be essential for planning the user experience. Of course, if one of the requirements for the project calls for allowing users to download scripts, it would be worthwhile to keep this concept in.

Level-Up Your Concept Model Skills

It can be easy to spin in circles (ha ha) with a concept model. Here are some things I watch out for:

Convergence: Everything wants to link to one concept

Though the hub-and-spoke model is a perfectly good way to represent how a central concept is the foundation for a series of interconnected concepts, the hub shouldn’t be the only concept everything links to. A model with a hub and one level of spokes without much more doesn’t help readers understand the rich array of relationships that drive the concept.

If you find yourself wanting to make statements about the same concept over and over again, a concept model may not be the right tool to describe the domain. Then again, you can try a couple techniques to breathe some life into the diagram:

• Take the central concept out. I know: crazy, right? When I find myself unable to express any relationship without linking to the central concept, I take the concept out and treat it as an assumption for all the other relationships. This helps me focus on the relationships between the concepts.

• Use a value proposition structure. Value proposition links three or four concepts together in a sentence, like “Concept models are diagrams that describe complex ideas.” Treating this as your central theme (instead of the single concept) gives you more opportunities to explore detailed concepts.

Keep the concept in perspective

You may be tempted to define life, the universe, and everything with a concept model. Once you get the hang of noun-verb-noun, your inner 18th-century philosopher will be clamoring to be let loose on the world. Why shouldn’t you be able to represent everything as interconnected circles?

Ultimately, you’re trying to explain a domain. Serving only yourself, the concept model doesn’t need to unearth the deepest assumptions. A model for readers will only be undermined by too much information.

There’s no litmus test to see if you’ve gone too far, but practice shows that most of my models include no more than a couple dozen concepts.

Keep the model practical

Stay three or four steps ahead as you’re constructing the model. You don’t want to censor yourself to the point of eliminating every concept. But you also don’t want to take your concepts down to the building blocks of life. Ask yourself these questions as your put the model together:

• Is this concept relevant to the target audience?

• How important is this concept to the business?

• Which relationships would the target audience prioritize?

• Can I imagine how these concepts will be turned into elements of the interface?

• Can I imagine some user research that would help me validate these concepts?

Answer “no” to any of these questions and you might be pushing into the realms of the impractical.

A concept model in the design process is like salt in a recipe: it sets the stage for a broader palette of flavors. Too much, and you’ll overwhelm the rest of the ingredients. To remain practical, a concept model has to just provide a foundation for inspiring, informing, and establishing context in the design process.

Presenting Concept Models

First things first: Ask yourself, “Do I need to share my concept model with team members or stakeholders at all?” If you’re using it as a tool to get things straight for your own purposes, or with a small team, this may not be a formal deliverable: It will never see the light of the conference room. It may be more responsible to shield your stakeholders and other team members from this kind of document if it operates at a level of abstraction that would be difficult for them to comprehend without concrete examples.

If you decide that the concept model includes ideas that are essential for understanding the overall approach, think about whether you need to show the entire model. Is there an abbreviated version you can put together that boils the ideas down to just what’s needed as prerequisites for the rest of the design? Alternatively, if the model yielded an insight or specific conundrum, you might assemble a separate diagram describing just the small piece.

Presenting a concept model means telling a story, putting the concept model into a context that team members and stakeholders can relate to. Your story needs to be grounded in reality, and this section describes several ways to do this.

Establish a Purpose for Meeting

The presentation should be driven by the purpose. With concept models, there are usually only two reasons why you’d present them: to prepare participants for more in-depth design discussions, or to hash out the model itself.

Preparing for design

One reason for presenting a concept model is to lay a foundation for the design, prepping the meeting participants for a more detailed discussion about the user experience. These meetings usually start out with, “I know you’re eager to dig into the design, but there are some basic concepts we need to clear up before we do.”

We could use our comics concept model (or a portion of it) to describe the design team’s assumptions in designing the web site’s interface. Those assumptions include answers to these questions:

• What are the most important categories of content?

• How do other types of content relate to those most important categories?

• What kinds of functions might users expect?

These kinds of meetings have at least one of these three key messages:

• This is a useful exercise because...: Be sure you understand how the concept model fits into the design process and where you’re going with it next. Prepare a simple rationale for doing the concept model, and refer to it when the meeting loses focus.

• Some initial design principles or requirements: Pull out a few of the insights and use these as themes or talking points throughout the discussion. These insights should be positioned as design principles or guidelines: They are boundaries and constraints that help the design team focus their efforts.

• Some remaining questions about scope: Highlight the areas of the model that remain unclear, or which called into question the scope of the project. The model may have revealed dependencies that would make the established scope challenging. The model may have identified additional requirements not yet incorporated into the thought process.

Analysis of the concept model may have yielded some initial ideas about design—which content will get its own templates, what the information priorities are, a metadata model. If you’re confident about your design decisions, you can use these as themes in the meeting. Otherwise, use them in the Communicate Implications section of the agenda.

Modeling together

The other reason to put a concept model in front of team members and stakeholders is to collaborate in its construction. In this case, rougher models are better because they lend themselves to feedback and discussion. It’s important to come to a consensus about the underlying structure that supports a web site’s user experience because it drives so many subsequent design decisions.

As described previously, concept models can help at any point in the design process. Building them collaboratively does not change this. You may come to an impasse in the design process, a clue that there’s disagreement about the underlying assumptions, and use that as an opportunity to take a step back and facilitate a brainstorming meeting to flesh out the basic concepts.

In these meetings, establish three key themes:

• Our focus is the scope: That is, the purpose of the exercise is to establish the boundaries of the domain. We want to get our arms around everything that may be relevant to the design problem. We can always remove concepts later.

• Our interest is in what’s missing: Participants should focus less on what’s there and more on what’s not there. They need to help identify concepts that may be important—even tangentially—and contribute to the overall picture of the domain.

• Abstract thinking is hard: Reassure participants that thinking about an information space in this way is not easy to do. We’re thinking about the web site not just as a series of building blocks, but as a series of templates. Some templates can represent so many different things that their structures look so far removed from the actual content as to be of questionable value. This is OK, and it can be hard to wrap your head around.

The meeting structure following assumes you’re preparing for design, not modeling together. If the purpose of your meeting is to present a skeletal structure for the concept model and engage participants in fleshing it out, you might skip steps 5 and 6. In these portions of the agenda, you provide details (you don’t have any yet) and communicate implications (which would be premature).

Adapt the basic meeting structure

The basic meeting structure from the introduction is ideal for concept models. As you delve further, you are uncovering more details. Keep an eye on meeting participants; they may start to lose the thread if you get too abstract. In this case, you’ve reached the end of the useful life of this meeting. Wherever you are in your agenda, transition to soliciting feedback and defining next steps.

Refresh your memory on the timing of sharing diagrams (Table 2.2 in the Diagram Basics chapter). With concept models (perhaps more than any other diagram) timing is important because stakeholders’ unfamiliarity with the models may add unnecessary challenges to the rhythm of your story.

1. Establish context

For concept models, which may occur early in the project, set the stage by explaining how this technique contributes to the design project. You can use this time in the meeting to clarify the parameters and boundaries you considered in putting the model together. Also provide a high-level description of your process—what sources you used, what it took to put the model together, and what you were attempting to capture in the model.

You can show the model, or the high-level version of it, when you conclude your context-setting introduction. This will set you up for the visual conventions, coming up next.

2. Describe visual conventions

Describe the model at a high level, first. The fact that the diagram consists of circles connected by lines may be self-evident, but it sets the stage for you to dig into the specifics.

If you’ve kept your model simple, limiting the range of styles for nodes and links, you may not need to say much more. If you’ve used a more elaborate set of styles, describe the types of contrasts those styles are meant to show.

3. Highlight major design decisions

It’s now time to dig into the model. There are three broad descriptions you can offer before getting too deep into the details:

• Overall structure: Indicate the three or four main concepts that constitute the main pillars in the concept model. Describe the relationships between them, and how they form the main structure that supports everything else.

• Unifying theme: Describe the underlying story in the concept model. For example, the theme for the sample concept model is the two sides of the comics business. Models using the “value proposition” structure (see Table 4.9) have their theme stated clearly.

• What’s in and what’s out: Distinguish the boundaries of the domain. This description is especially useful if you’re trying to zero-in on scope, and you need to clarify that you’ve left some things out of the concept model on purpose.

Before moving on, this is a good opportunity to show the value of the model by describing insights that came from creating it. Some of these insights might include:

• New concepts essential to the experience: Through your research or brainstorming, you might have identified a concept that is a useful piece of information for users, or is a category that unites several other concepts together.

• New relationships between concepts: Concept models represent your priorities very clearly. Through modeling a domain, you make specific choices about what concepts to connect, and some of these links may represent a new spin on the information space.

• New perspectives on the experience: In creating the concept model, you may have stumbled upon a new idea for structuring the overall user experience. This may be a new navigation scheme or a new way to arrange the content templates.

4. Offer rationale and identify constraints

Meeting participants might still be noncommittal about the concept model, not sure why they’re talking about circles and lines when (clearly!) there are bigger issues at stake. Use this portion of the meeting to reiterate the purpose of the model, how it fits into the project, and what you hope to get from the conversation.

Use this time during the conversation to describe research you did to feed the model. Indicate what sources you used to generate lists of concepts and identify potential connections between them. Such discussion may trigger ideas from participants on other places you can look to flesh out your understanding of the domain.

5. Point out details

Describing concept models in excruciating detail is useful only if you expect to get meaningful feedback at those deep layers. There’s no need to hit every circle in the diagram unless you only have about a dozen concepts. Otherwise, use this time to point out a few of the detail areas:

• Novel concepts: If you’ve added any concepts that stakeholders might not expect to see, dig into these and be explicit about where the concept came from and why it’s important.

• Insights: Assembling the concepts in this visual format may have yielded unexpected insights. Describe these areas of the concept model.

• Challenges: To transition to the next part of the agenda, you can draw participants’ attention to areas of the model that imply difficult design challenges.

6. Communicate implications

For concept models, where the rubber meets the road is in how the model will lead to design. Most of this chapter is dedicated to creating the model in the context of a design project, so hopefully you’ll have some ideas about what you’re getting out of the model. At the very least, you should be able to describe at least one of these things:

• A better understanding of the domain: But merely saying that you understand the domain after so many hours of putting together a concept model is a bit of a letdown. Be sure you have something else to share.

• A better understanding of the target audience: Better, but why didn’t you do personas?

• A prioritized list of requirements: This is good. The concept model helped you prioritize areas of the project: which parts of the site you’re going to work on first. Why? The concept model told you to do it.

• A list of potential challenges: This is also good, and it shows you’re thinking ahead. The concept model helped you identify relationships that will be difficult to communicate, concepts that will require lots of links, or processes that are not straightforward.

• An inventory of possible screens: This is best. The concept model yielded a set of concepts and relationships that helped identify a list of screens that you need to design for the user experience. It provided a foundation for the site’s underlying structure.

When discussing concept models, you may need to jump ahead to this section: people may just want the bottom line. With concept models the conclusion is, “So how does this impact the design?” And there’s no reason to save the implications for last if they represent the most important conclusions from your work.

7. Solicit feedback

You’re interested in getting input on four things:

Table 4.10. A structured look at feedback helps ensure you get what you need.

8. Provide a framework for review

The next steps after a concept model discussion are all you, the design team. I can’t think of an instance where I sent off a business stakeholder or developer with homework to review the model. It’s an introspective tool, and we’ve let others in to see our thought process, maybe to validate it in real time.

But the lack of context when reviewing it “offline” would make it difficult for others to provide meaningful feedback (unlike a flow or site map or wireframes, which are more concrete).

Instead, clearly state where you’re going from here.

Avoid newbie mistakes

Even the most concrete concept models can confuse participants. Unless they can draw a parallel to something in the real world, they may not understand exactly what they’re looking at. And even if they do get it, they may not care.

Potential response 1: I don’t get it.

Some people may just not get it, especially if the concept model dabbles in the really abstract. Models can represent categories of categories or tiny little blocks of data or information about metadata (which is information about information). They can use slight variations in visual conventions to represent different abstract ideas (arrows for navigation, arrows for transporting data, arrows for indicating semantic relationships). For people who are used to looking at spreadsheets, or the simple infographics in USA Today, these diagrams can be exhausting.

Before going into a presentation where you think you might get this response, boil the concept down into three sentences. If you’re not getting anywhere with the diagram, whip out those bullet points. As you watch your meeting circling the drain, these three sentences can be a lifesaver, giving participants the essential message without belaboring the diagram.

The key here is to not make them feel dumber than they already do. To that end, you might say something like: “Why don’t you take some time to digest this and give me feedback in a couple days? This model is important because it creates the overall foundation for our design work. While you’re looking at it, keep the following three things in mind. (Insert your summary sentences here.)”

Potential response 2: So what?

Even if the meeting participants get it, they may not realize why it matters. You have two possible strategies in this situation: Try to show the connections between the model and the design, or simply cut the meeting short.

Cutting the meeting short is always an embarrassing and difficult tactic, but sometimes you have more to gain by avoiding conversation than forcing it. Since concept models tend to be highly abstract tools for designers to get their thoughts in order, the stakeholders may have little to gain by going through it.

Again, the key here is to not make them feel stupid. Try saying something like: “I think I’ve gotten everything I need. I appreciate your time. We’ll take this feedback and incorporate it into the design. If you have further thoughts, let me know. Otherwise, the next time we talk we’ll start to show you some of our design work.”

Ending the meeting is a last-ditch tactic, and you should only use it if it’s clear the stakeholders or other team members aren’t interested in engaging at an abstract level.

Applying Concept Models

Though potentially highly disposable, concept models can also have a long shelf-life to help drive ongoing design activities.

Providing Context for Other Deliverables

Once the model is complete, I’ll stick it at the front of other deliverables. They provide a nice visual for stuff that usually comes at the beginning of the document: what is the problem we’re trying to solve, what principles drove our design decisions, what is the relationship between the site’s audience and content, what is the scope of our design project.

This is only meaningful if the concept model actually provided specific inspiration for the remainder of the document. Perhaps the model helped you identify what screens to build or seeded the idea for the site’s navigation strategy. If this is the case, the model can help tell that story as well. Besides the diagram itself, you might include some narrative text or at least three to four conclusions (“key take-aways”) drawn from the model.

On subsequent pages of the document, the model can provide more specific context. You can miniaturize the diagram, scale back the color, and use deeper saturation to highlight the relevant area of the model for each wireframe or persona or what-have-you.

From Model to Screens

If point A is the concept model, what’s point B? Where do you go from here? Ultimately, concept models should frame a domain such that you have a good handle on the range and depth of information the web site needs to accommodate. If you’re having trouble making that leap, from model to screen design, here are a few ideas to get you started:

Concepts as screens

Any node in the model might be a good starting point for designing screens. Pick one and decide how the web site should represent that concept.

Remember that nodes represent abstract concepts, generalizations across swaths of information. The “issue” concept in our comic book model can represent one of many different examples of a single issue of a series. Therefore, the screen we design to represent “issue” is a template or container: It has spaces in it to display information about a specific instance of the concept.

Some nodes adjacent to the concept you picked relate to it in some way. Your screen should show how users might navigate to that kind of information. How do users, for example, get from a single issue to a page about the whole series? How do users get from a single issue of a series to a page about related series? How do users get from a single issue to everything authored by the issue’s writer? Or everything in the series authored by the issue’s writer?

Figure 4.17. Identifying the insights gleaned from a concept model is one way to establish a set of design requirements. In this case, the page from the document also acknowledges what’s missing from the model.

Figures 4.18. Questions about navigation, embedded in the concept model itself, provide a powerful way to (a) highlight the relevance of the model and (b) provide a mechanism for focusing discussions.

Concepts as metadata

Some nodes are descriptive, providing details about the concept. Issues have numbers. They are a chapter in a story arc. They might have a summary of the plot. All of these are potentially useful pieces of information, but not enough to serve as navigation mechanisms (they don’t bridge to other concepts). Nor are they substantive enough to yield pages in and of themselves. Yet the concept model helps us see that they need to be represented on the main screen somehow.

Models to inspire structures

In the previous examples, we’ve considered the concept model to be the basis for the site’s underlying architecture: Each of the major concepts translates to a template; the links between the concepts correspond to links between the templates. Site designs, however, may not be translated so literally from a concept model.

Figure 4.19. Some concepts make good metadata elements. In this version of the model, candidate metadata elements have been marked with a little tag icon.

For a recent project, I created a concept model that helped me look at the domain in a new way. Instead of designing a site structure driven by content type, I suggested designing templates based on lifecycle. To be specific, everything that passed through the system, regardless of its format or content, went through a similar lifecycle. The target audience wasn’t concerned as much about format or content as they were about where something stood in the lifecycle: that was the factor that changed the decisions they made.

Can we do this for the comic book model? Does it suggest any other ways for structuring the information in a meaningful way? The model reveals some potentially useful structures and contrasts:

• Reading vs. collecting: These two activities are more than just use cases; they represent different relationships to comics. What’s worth exploring is whether they can be served by the same web site and where the web site should be split to accommodate these two distinctions. Does an “issue” page template need separate tabs to display two different kinds of metadata? Do readers and collectors browse for comics differently?

• Character timelines: Working through the concept model helped me establish a clearer picture of the relationships between a character, its “mythology,” the ongoing story lines, and the continuity between all of them. This is a situation unique to comics, especially mainstream comics. A single character can appear in multiple books at the same time. Most readers care about which story line represents the “canonical” history of their favorite character. Could we design an interface that focuses on character history and show the relationships between those timelines and the published issues?

Relationships as interactions

Finally, you could look at the relationships between concepts for inspiration on interactions. Verbs in the model may directly translate to actions users can take on the site. They might inspire functions or features you hadn’t considered. They might shed light on the requirements.

These four techniques are hardly mutually exclusive. Picking one as the means for driving design does not mean the others won’t offer equally useful inspiration.

Concepts Matter

Imagine a concept model, designed for a news publishing service, that describes the anatomy of a news story. It shows how the news story is composed of different kinds of information, the metadata attached to a news story, and the different types of news stories displayed on the site.

The concept model establishes a vocabulary for talking about the structure of these stories, and how they might be formatted in different ways on different parts of the site. The front page will have short teasers. Subject category pages might have longer teasers and a couple of features with longer introductions. The design team gives all these data points distinct names so they can talk about them easily: short summaries, headlines, subheads, long summaries, main body, extended body, and many others.

For all the effort put into this terminology, it may never be exposed to the end user. Its purpose is simply to facilitate the design process, to come to a common understanding of how the underlying concepts relate to each other. It is through the final design that the people using the site are intended to understand these concepts. Ironically, the design needs to be more effective than the concept model in communicating them.

And yet, many designs couldn’t get off the ground without some kind of conceptual model. This won’t change anytime soon, and with web-based systems becoming more complex and richer in their interactions with users, concept models will be more critical than ever to the planning process. Web sites whose navigation systems rely more on searching than browsing, or that depend on organic growth with content contributed from users, or that simplify information delivery through syndication, will require more conceptual designing up front. The concept model may become a more central tool in the process of designing web sites.

Exercises

1. Pick one of the following “systems” and create a concept model describing it, but don’t use the word itself in the model. The challenge here is separating the system from the processes associated with the system. For the library, for example, your model shouldn’t be a step-by-step description of how to check out a book. Instead, it needs to provide an overview of all the different things that make up the library and describe the relationships between them. Even if you can’t use the name of the system, you can use nouns and verbs that evoke the system.

   

2. Show someone else your concept model and see if they can guess what system it describes. Once you have that out of the way, practice walking through the model and soliciting feedback.
3. Create a model like the one for comics for your favorite medium (television cop dramas or sitcoms, a specific genre of music, period literature, children’s books, and so on). Don’t be afraid of getting too specific. One of the most memorable models I’ve seen mapped different varieties of dance music, showing not only the relationships between them but the beats per minute along a scale. Your model should describe the experience of the medium from as many angles as possible, but you may decide to limit the depth. (Do you really need to talk about camera operators or technical consulting in the production of a television show?)
4. Use the model to map out a web site (or other product) that supports, enhances, or commercializes the experience of the medium you selected. Identify two or three approaches for designing and structuring the site, inspired by the concept model. Your approach need not be elaborate. Instead state in a few sentences (or with a picture) how you intend to architect the site: What are the main templates and navigational mechanisms? What is the range of content you’ll support? What kinds of things will users be able to do? Reference the concept model (perhaps through color coding?) to provide a rationale for your approach.